\subsection{PAMS - A generic collaborative framework for agent- based simulation of complex system}

\begin{figure}[!t]
\centering
\includegraphics[width=\linewidth]{imgs/Fig2-2}
\caption{Evolution for multiple interface structure}
\label{fig:Fig41}
\end{figure}

\begin{figure}[!t]
\centering
\includegraphics[width=\linewidth]{imgs/Fig4-code}
\caption{DTD structure}
\label{fig:Fig4}
\end{figure}


To illustrate our design of a multiple interface we have to implement it into a collaborative environment supporting or even better dedicated to the simulation. This environment should also be extensible enough to be extended with our multiple interface module. We choose to integrate it into the PAMS portal \cite{PAMS:2009}.

PAMS is the result of our attemps to develop and deploy methodologies and tools for supporting the collaboration between domain experts, modelers and computer scientists while working with different simulation models based on different agent-based simulation platforms. In PAMS, models, simulators, experiments and results are placed at the center of the collaboration in offering collaborative tools.
Its design has the advantage to be fully modular and thus easily extendable.
Each simulation platform is integrated into PAMS as independent packages such as NetLogo or Gama. This structure is detailed in \cite{PAMS:2008}.

%% in Figure \ref{fig:Fig21}. The box \emph{simulators} is the core package (or the kernel) of the simulation platform. Each simulator has a specific \emph{driver}. The \emph{simulator controller} refers to the connector package that integrates each simulator in the system.

%%In such a structure, we can integrate easily a new simulator by implementing a specific driver for the new simulator. Besides, PAMS can manage various models for one generic simulation platform. The \emph{single interface controller} package is the connector package that displays the specifications of each simulator (display outputs, possible inputs, actions that can be performed on the simulator...) in the graphical interface. This structure is detailed in \cite{PAMS:2008}.

In a such architecture, we can integrate easily a new simulator by implementing a specific driver for the new simulator. Besides, PAMS can manage various models for one generic simulation platform. Moreover it manages ad hoc simulators (\emph{e.g.} MIOR simulator) and simulation platforms (Repast, Netlogo and Gama) as black-box defined by their inputs and outputs in order to display them all in a common GUI.

%%The \emph{single interface controller} package is the connector %package that displays the specifications of each simulator (display outputs, possible inputs, actions that can be performed on the simulator...) in the graphical interface. This structure is detailed in \cite{PAMS:2008}.

Currently, PAMS provides to all the participants a common collaborative interface for the simulation, coupled with collaborative tools like video conference, whiteboard, instant messenger with which they communicate and interact. The common interface of the current version of PAMS includes a parameter panel to initialize and modify parameters of the model, a control panel to run the simulation model, a display panel to observe the evolution of the simulation and a monitor panel to observe variable values.


\subsection{Implementation}


%With the current version, PAMS provides a common collaborative GUI for all participants. Users can initialize and modify a set of parameters. They can add a new and view the displays, monitors and graphes or control the simulation process of a model.


%However, as discussed in previous section, participatory simulations do not need only collaborative tools but %also various views and control on the simulation.

%The current interface of PAMS difficult to modeling the specific behaviors of each type of agent because social actors have the same views and control rights on various types of agent through a same role in a simulation process. In fact, an actor of collaborative work gives effectively their decision in their knowledge. After that, thanks to their individual and teamwork experiences on their specialized field, results are better.

%They give only the best decisions if they are assigned exactly view and control rights on agents on the knowledge bases in their field.

%The generic design highlights that a participatory simulation should have a multiple interface. To build such %an interface, at first we should make the design, define, assign different roles of a simulation model to %participants. Each role get the personal control rights or personal views and modifications of parameters and %outputs.


%%One of the difficulties to become a group-ware that supports the participatory simulation is thus to design a %generic, extensible, modular and flexible approach (\emph{i.e.} meta-model) that defines easily the roles. It %must be generic enough to adapt to all models because each simulator has its own specifications.

%%\subsubsection{Multiple interface customization}


\begin{table*}[!t]
\renewcommand{\arraystretch}{1.3}
\caption{Elements of any role in DTD structure}
\label{table_example}
\centering
\begin{tabular}{|l|l|l|}
  \hline
  % after \\: \hline or \cline{col1-col2} \cline{col3-col4} ...
  Tag & Name & Description \\
  \hline
  \hline
  ELEMENT & Simpart & Element ``root'' that contents various roles \\
  \hline
  ATTLIST & Model & Attribute indicate ID of the model \\
  \hline
  ELEMENT & Role & Element ``role'' represents a role that contents various rights. Each right is a tag \\
          &      & ``accesscontrolview''\\
  \hline
  ATTLIST & Name & Attribute that indicates the role name \\
  \hline
  ATTLIST & isControlSimulation & Attribute that specifies the right to launch the simulation. Default: he can. \\
  \hline
  ELEMENT & accesscontrolview & Element represents every right of role. Its value is the name of the parameter or  \\
       &                      & of the output that is saved in the mySql database. \\
  \hline
  ATTLIST & type & Attribute that indicates the type of parameter or of the output. Default: parameter \\
  \hline
  ATTLIST & isControl & Attribute indicates the right to modify a parameter. Default: He cannot. \\
  \hline
\end{tabular}
\end{table*}


To extend the existing architecture of PAMS with multiple interface requirements, we introduce a new module separating the common interface into personalized interfaces. We chose to specify the various interfaces via an XML configuration file, that will respect
a DTD built from the UML meta-model proposed above. This DTD is presented in the Figure~\ref{fig:Fig4}.

Thus to customize the user interface, the modeler has to define the roles, \emph{i.e.} determine the elements that a user playing a role is allowed to display on the interface and controls that he is allowed to use (\emph{e.g}. I/O variables in Section III). All these elements will be stored in the XML configuration file.

%% With the generic structure in previous section, we need to design a XML file (associated to a DTD structure for the validation) that save the definition of the different roles of a model. Furthermore, when we want to change these roles, it is simple to modify the content of the XML file instead creating a new one. In addition by using the XML structure, you do not need to change the current database or other entities.

%The difficulties of separating the common interface into a multiple interface are the way to parameterize the multiple interface and how to save the roles of each model. When you need a large memory space to store the results of the execution of a program, you will use an SQL database. Indeed the SQL database can manage the addition, deletion and modification of data. However, when we want to store data with a predefined structure, a stable value and that require only a small memory space, a XML file (associated to a DTD structure for the validation) is simpler and more effective. In our case, we need to describe the content rather than the presentation of content. We only need a structure to save the definition of the different roles of a model. Furthermore, when we want to change these roles, it is simple to modify the content of the XML file instead creating a new one. In addition by using the XML structure, you do not need to change the current database or other entities.

%First we need to list elements that can be displayed in each interface, then to organize them into a meta-model of the role from which we will determine the DTD of the role description XML files.



%According to above schema, we can give the structure of the DTD document (Figure \ref{fig:Fig4}) that describes the grammar of the XML files that will define the various roles and will be used as configuration files for the multiple interface.


%
We consider that one XML file describes at most one simulator. The root element contents different roles for the model that is specified by the attribute ``model''. Each element ``role'' has a private name defined by the attribute ``name''. A role has different rights that correspond to the tags ``accesscontrolview''. Furthermore, the right for a role to control the simulation (launch, stop, start, pause) depends on value of the boolean attribute ``isControlSimulation''. The value of a tag ``accesscontrolview'' correspond to a name of an input or an output of the simulator. It indicates that this role has the right to view this element. The tag ``accesscontrolview'' has an attribute ``type'' to determine whether this element is an input or an output. Finally, the boolean attribute ``isControl'' will specify whether this element can be controlled by this role. We summarize this description in the Table \ref{table_example}.

Given from XML file and the simulator archive, we can upload and setup a simulator, automatically thanks to a web page.

After having proposed a meta-model and integrated it into the PAMS portal, we present an application case on
the GAMAVI model to validate our implementation.

%After having proposed the meta-model and the DTD of the XML configuration files for the multiple interface, the integration has required one more steps. We needed to give the possibility to the users to upload their XML configuration files on the server.




%We thus introduce a new module (technically an EJB) that can turn the single interface controller module into a multiple interface controller module (XML-based multiple interface controller in Figure \ref{fig:Fig41}). Integration of the multiple interface into the PAMS platform will not modify deeply the existing interface: we will specialize panels allowed for each role and each panel will only keep the elements allowed for a particular role.


% The third step is to develop an EJB module with an XML parser that can read the configuration file and produce the new interface dedicated to each role. This interface is called specialized interface.


%\subsubsection{XML-based solution}
%
%
%According to above meta-model, we can give the structure of the DTD document (Figure \ref{fig:Fig4}) that describes the grammar of the XML files that will define the various roles and will be used as configuration files for the multiple interface.
%
%We consider that one XML describes at most one simulator. The root element contents different roles for the model that is specified by the attribute ``model''. Each element ``role'' has a private name defined by the attribute ``name''. A role has different rights that correspond to the tags ``accesscontrolview''. Furthermore, the right for a role to control the simulation (launch, stop, start, pause) depends on value of the boolean attribute ``isControlSimulation''. The value of a tag ``accesscontrolview'' correspond to a name of an input or an output of the simulator. It indicates that this role has the right to view this element. The tag ``accesscontrolview'' has an attribute ``type'' to determine whether this element is an input or an output. Finally, the boolean attribute ``isControl'' will specify whether this element can be controlled by this role. We summarize this description in the Table \ref{table_example}.


%\subsubsection{Integration}


%To integrate the participatory structure into PAMS, we must rely on current structure of PAMS and generic conception in Section III. Actually, PAMS does not support the agent events manager. In other words, user can only have permission to control (\emph{e.g.} can launch or only view their results of) the simulation. PAMS designed three accessors: monitor, graph and display to show results of simulation. And more, to invite participants into a modeling process the modeler can attribute a predefined role in XML file for each user in turn. We have a shortened participatory schema in the case PAMS in Figure  \ref{fig:Fig42}. The main key is \emph{Role}. With distributed \emph{Role} before each modeling process, user has rights to view the results of simulation or control it. The permission \emph{View} defines the visible parameters( through \emph{Parameter\_View} right) and outputs (through \emph{Result\_View} right) of the simulation user can observe or add a new into their control panel. User can trace simulation process through three control panel of accessors. The permission \emph{Control} permits users to modify the initial value of parameters (through \emph{Parameter\_Modification} right) or control the execution of simulation (through \emph{Simulation\_Control} right).



